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Description 

Virhial Server %stetn For Dynamic Con tent In World Wide Web Pages 

TffchnicatHgld 

The present invention relates generaUy to the field of aeating interactive World 
5 Wide Web display documents for use aver the Internet and more particularly to 
a virtual server for automatically generating web pages containing dynanuc 
content. 

Barkgroimd 

The explosive growth of the Internet and the World Wide Web (the Web)' in the 
10 last few years has been accompanied by an ever-inaeasing use of the Internet and 
the Web for btisiness and commercial purposes. However, most of the tools, such 
as the Standardized General Markup Language "SGML" and Hypertext Markup 
Language ''HTML" languages and page generation tools which have been 
developed to allow individuals and companies to create Websites, assume that the 
15 content of a Website will be relatively static. HTML, for example, does not provide 
any syntax for dynamic content. For a retail website designed to display a retail 
catalog and price list tttat changes only once every few months, tfiis tends not to 
be a problem, if products and prices do not change more rapidly. However, as 
more dynamic business applications are projected for the web, ttie need to 
20 transmit "live/' current data through the website has increased dramatically. The 
proposed extensible Markup Unguage "X^IL'^ and extensible St>ae Language 
"XSL" formats should assist in standardizing the format for dynamic content but 
there are few, if any, tools which allow a statically defined website to handle 
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dynamic content changes readily. Consequently, those businesses sedcing to 
develop such appUcations will typically need to hire skilled information 
technology (IT) resources to do so. 



The illustration in Figure 2A(Prior Art) shows the different types of IT skill levels 
5 that this might ^tail. Presently, the simplest IT skill level is shown at level AA^ 
where WYSIWYG (Wlial You See Is What You Get) design tools such as 
DREAMWEAVERTM and FRONTPAGE™ provided by Microsoft, allow graphic 
designers to design web pages and to control the contents of them. Ideally^ as 
level AA indicates^ a web designer is likely to be able to use HTML (Hypertext 

10 Markup Language). This is a relatively simple, easy to use language that allows a 
v^^eb designer to "mark up" text and graphics in a web page so they will display as 
desired at the user's web browser As the WYSIWYG term implies, WYSIWYG 
tools allow a designer to manipulate symbols and graphics in such a way that as 
the designer places them on a webpage, they can be viewed as they will appear to 

15 a user. For the typical static content of most websites these tools have eliminated 
the need for training the web designer in the details of IT and more advanced 
programming skills. 

To the extmt that the owner of a commercial website wishes to indude the kind of 
dynamic content associated with many business applications, some higher level of 
20 IT skill will usually be required to accomplish this. As shown in Figure 2 (Prior 
Art), as the IT skill level needed ascends the pyramid shown, resources tend to 
become scarcer and usually more costly. This is true even with the advent of XML. 
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For example, if a user wants to develop an application that pennits use of a 
volatile, rapidly changing internal database over the Internet, it is very likely that 
dynamic queries made against the database will turn up a variety of responses. 
HTML does not allow a designer fco specify content as dynamic Most present 
5 design tools have non-standard extensions to HTML that allow a designer to 
include some dynamic data. However, since these are non-standard extensions, 
the designer may be locked in to one tool Also, they usually require additional 
training of the designer. Most problematic, however, is the fact ttiat tiiey are 
likely to intermingle data access design logic with display design. 

10 These tools also may or may not be able to handle some of the more complex 
types of repeating fields in dynamic data. Problems frequently arise when the 
application under development attempts to map columns C1-C5, in a database, 
such as database 00 in Figure 3(Prior Art) to field F mappings in a web page 15, 
when the columns or the field contain hierarchical node components. Thus, Fl in 

15 webpage 15 may actually require several hierarchical sub -fields F1-F4 to display 
the hierarchy of subset data foimd in a column C in database 00. Conversely, in 
some cases a query made by a user against the database 00 may require the data 
access design to resolve repeated rows of data from database 00 into an 
aggr^ted doomient for display on rhe webpage 15. In order for such multiple 

20 results to be displayed on webpage 15, additional custom programming beyond 
the IT skill level of the typical web designer has usually been required. 

The prior art tools usually put dynamic data directly into HTML formatted pages 
physically stored on the website, if they are able to handle dynamic data. Today, 
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many users woudd prefer to be able to put the dynamic data into XML format 
first to take advantage of its tag labeling features. HTML only defines formatting 
- -XML allows a user to classify the data using tags. For example, HTML only 
allows a user to format the appearance of the words ''Charles Dickens"/ while 
5 XML allows a user to tag those words to indicate he is an author. 

Present techniques for solving the IT problem, even with existing tools, usually 
involve having an U professional who is skilled in Java or C++ or other languages 
work in serial with the web designer. Typically^ the IT professional develops data 
access logic to provide tf\e data for ti\e web designer's page design. As shown in 

10 Figure 2B(Prior Art) this data access logic is usually embedded in the server 

enabled page 40 as a data access component 42 (an object or piece of code) or as a 
server side call 44 within a static HTML document. This means that die page 
design or "look and feel" of the website or application is tied together with data 
access and processing and vice versa. Page designers cannot re-design for look 

15 and feel widiout also affecting the data access design. Data access logic carmot be 
re-designed without also affecting ttie page design. 

This also means designers and IT professionals must interact more than they 
mi^t othervsdse need to do. In normal developments this occurs serially. That is, a 
page designer may propose a layout which then has to be reviewed and 
20 accommodated by the data access FT persoimeL If IT personnel think data access 
logic can be developed or modified to accomplish it^ IT approves it and proceeds 
with development If IT does not approve, several discussions may be needed to 
identify compromise solutions. Similarly, changes in the data access logic which 
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might necessitate changes in the page document display will have to be reviewed 
and accommodated by the graphics page designer. There can often be several 
iterations back and forth before final common specifications are agreed upon- This 
tends to cause delays and loss of productivity, as well as a greater chance for 
5 design errors. 

With the interdependencies that exist between page design and data access design 
in this approach, other errors can arise easily based oxi misxmderstandings 
between persons with different skill sets. What may seem to be an obvious page 
design requirement based on the data access logic design may not be obvious to a 
10 graphics designer handling the web page. Similarly, a page design that optimizes 
attractive display and ease of use may not appear so useful to the data access logic 
personnel if it makes tfieir jobs more difficult Tbese discrepancies may not 
become apparent until well into tfie development cycle when the page design is 
first used in connection with the data access design. 

15 Similarly, the business application being developed for the Intemet may require 
that the web page designer and the data access designer allow a user to 
conditionally extract data for certain kinds of queries. In these cases, one field in 
the webpage may need to relate back to many columns of data in the database 00 
badcend or vice versa^ depending on the data values or the context of the query. 

20 If the business wants to enable the web browser user to update a database GO, 
additional complications can arise. Is the update an addition, a deletion, or a 
change? How is the data sent to the web server handling the webpage and the 
database to be used? What formats arc required? The web server protocol HTTP 
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used by desigriers of HTML documents operates on the principle of 'Vequest and 
return". This means web servers can deliver rich formatted information inside the 
web pages they serve, but they can only accept relatively simple information from 
within a request that is sent by a user at a web browser. Specifically/ when a web 
5 server receives information^ it natively accepts only a simple list of HTML 
parameters and their values. These parameters are either attached to the URL 
directly or are sent separately from the URL when submitted from a form using 
the POST method. Present attempts to address this problem with existing tools 
require even more special progranraiing and exceptions. 

10 For more complex business applications, automatic retrieval and processing of all 
information needed to make successive data access requests based on the results 
of tite current request may be desired* In this kind of systan, the application 
allows the user at a web browser to submit requests that "drill down" tiirough 
multiple levels of data detail in the backend database (DO to find very specific data 

15 knowing only general information about its location. The problem faced by the 
data access IT person and the graphics person occurs when they try to make tiie 
system automatically determine the navigational information required about the 
location of the specific data, so that each successive request can be defined and 
alteted independently of the other requests, but in such a way that the links 

20 between them are automatically maintained. For example, if the database contains 
a list of employees, and the user at a web browser only knows that she wants to 
find an employee named Joe, who lives in the Northeast, she might search the 
database for all employees named Joe. To find a specific one^ the user might 
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request all those named Joe Smith. When ilte user sees Ihe list she sees one living 
in Boston Massachusetts and one in Nashua, New Hampshire, If she remembers 
the area code, she can ask again to see the one with area code 603, which is the 
New Hampshire Joe Smith.Retrieving all the necessary information required so 
5 that a user can perform this kind of search is a significant challenge for present 
tools. 



Recent industry projections indicate that the aeation of a simple website with 
static displays can cost a company anywhere from several thousand US dollars to 
hundreds of thousands of dollars. Many business organizations may also have 
10 existing internal databases and applications programs they have spent thousands 
or millions of dollars developing. 

At present, programming language tools for the Web, such as ASP*^^, provided 
by Microsoft and COLDFUSlONF^'s CFML^" provided by Allair, attempt to 
offer businesses a way to integrate the dynamic content of backend databases 

15 with statically defined website pages, but these tools involve using a specially 
developed proprietary language with its own complexity and h«ice, the need for 
a higher IT skill level. CFML, for example, has over 200 different commands a . 
desagner might need to leam. These tools as well as custom programmed efforts 
writta\ in Java or C++ also tend to require the embedding of code in the webpage 

20 documents. This code is usually executed at run-time eadi time requests are made 
for dynamic data. As seen in Figure 2B(Prior Art) tiiis can also slow down the 
overall execution of queries made at run-time over the Web. 
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Present attempts to design or modify web pages to incorporate dynamic data 
content are thus hampered by the potential need for higher^ more expensive and 
scarcer IT skill levels, costly development tiirtes and delays, and final products that 
may be comparatively slower in execution time. Additionally, some current 
techniques require a user to include programs written in proprietary languages or 
custom-developed programs. 
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Smmiaicy 

A virtual server system for generating dynamic content and a display document 
therefor to be sent over a network is disclosed which automates the retrieval of 
dynamic content and uses previously defined style and content definition sheets 
5 to format the display document. In the embodiment shown, dynamic data is 
accessed from a database^, in any of a number of formats and schemas, using data 
access definitions and parameters generated at design time. The virtual server 
uses a previously defined XSL style sheet document cmtaining the static 
formatting desired and an XML DTD document defining the dynamic content to 
10 be applied to the data to generate and serve the requested display document 

It is an aspect of the present invention that no physical display document is stored. 

It is another aspect of the present invention that a display document can be 
generated at runtime by a virtual server which not only creates the document but 
also accesses any dynanxfc data r\eeded in the display. 
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ftirp^f p^srripHon of the Drawings. 
Figure lA is a block diagram of tt\e present invention. 
Figure IB is a schematic drawing of the present invention in use. 
Figure IC is a block diagram of illustrative syntax used by the invention. 
5 Figure ID is a block diagram of illustrative syntax used by the invention. 
Figure IE is a block diagram of illustrative syntax used by the invention. 
Figure IF is a block diagram illustrating the formatting of repeating rows. 
Figure IG is a block diagram illustrating the formatting of nested tables. 
Figure IH is a block diagram illustrating the formatting of nested tables. 
10 Figure II is a block diagram illustrating the formatting of repeating buUeted lists. 
Hgure IJ is a block diagram illustrating the formatting of repeating form 
elements. 

Figure 2A(Prior Art) is a block diagram of skill levels required by the prior art. 
Figure 2B(Prlor Art)"is a block diagram of prior art techniques. 
15 Hgure 3 (Prior Art) is a schematic diagram of a prior art access to a database^ 
illustrating a problem. 

Figure 4A (Prior Art) is a block diagram of server processing in the prior art. 
Figure 4B is a block diagram of server processing using the present invention. 
Figure 4C is a block diagram of the present invention in operation at runtime. 
20 Figure 4D is a block diagram of a visual mapper of the present invention. 
. Figures 5-15 are flow and block diagrams of the present invention. 
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Detailed Descripti on of the Inventian 

In Figure lA an ovemew of the present invention is shovm. An input page 15, 
which is being designed by a web designer, is depicted. Web pages such as input 
page 15 designed in standard HTML for the World Wide Web usually contain 
5 formatting definitions 15a and static content 15b, Working in conjunction with the 
web page designer's choice of designer tool 13, the present invention's dynamic 
content identifier (DCI) 18 evaluates the syntax used by the designer to create the 
page. Using a spedal, simplified syntax and context analjreis discussed below, DCI 
18 splits input page 15's elements into those which are static content and those 

10 which are djiiamic content. In the embodiment shown, DCI 18 creates an XSL 
compliant style sheet 25, which describes the formatting 26 of the static content of 
input page 15, DCI 18 also creates a dynanuc content definition 28, in XML 
compliant Document Type Definition (DTD) format. At design time a data access 
designer uses page request definition generator 19 of the invention to create data 

15 access definitions 32b, which are input parameters for the invention's page request 
object handler 3Z When a web page such as input page 15 is requested from the 
present invention's virtual server (described below) at runtime, the invention's 
server applies style sheet 25 and dynamic content definition 28 to the content 
retrieved dynamically from a database to produce a fully formatted HTML page. 

20 This is performed by server objects 30, w^hich include server and data access core 
code 31 and a page request object handler 32. Page request object handler 32 in 
the embodiment shown includes a handler routine which accepts parameters 
generated at design time by page request definition generator 19. These 
parameters define how to access the data in a database and how to map that data 

25 into XML format. The parameters also define how to connect to the database, how 
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to login^ how to generate queries against it, and so on. 
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Despite the fact that HTML at present has no support for dynamic content, the 
present invention's dynamic content identifier (DCI) 18 allows designers to define 
all formatting for dynamic content using existing standard HTML tagS/ using any 
5 type of HTML editor or designer topi 13. In the embodiment shown, DCI 18 
operates as a separate tool from designer tool 13. However^ it could abo operate 
as a subset or extension of a designer tool 13. DCI 18 recognizes spedally prefixed 
field names and attributes, and contextual data to automatically generate an XSL 
compliant style sheet firom the HTML input page 15. 

10 Figure IC illustrates some of the general types of specially prefixed field names 
and attributes- In the embodiment shown, a default prefix 80 such as "psx" can be 
used by the web designer to identify dynamic content. While the examples shown 
here use psx, another prefix could be supplied by the designer at the initial 
configuration of the system. 

15 Still in Figure IC, a web designer can tise the default prefix 80 with any fidd 

names 82 that conform to the XML sjmtax. Note that these field names are written 
in HTML by the designer, but conform to XML S5mtax. Since XML field name 
syntax requires all fields to share a common ''root" node name, the present 
invention automatically generates a "root" node name for all fields in the HTML 

20 document* The root node name comes from the base names of the HTML display 
document that is bemg analyzed by DCI 18. For example, assume that in Figure 
IC, field 82c "psx-name/first" is contained in an input page 15 called person-htm. 
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In this example, the present invention gives field 82c the full name 84 of 
"person/name/first" and the associated DTD document 86 is called "person.dtd". 
In tliis example, the root node name is "person." Any field names 82 in the 
HTML document input page 15 which already use the correct root node name are 
5 not altered by DCI 18. 

Turning now to Figures ID, and IE, two types of spedal syntax recognized by the 
present invmtion are illustrated. Figure ID illustrates exposed syntax and Figure 
IE illustrates hidden syntax. 

First, in Figure ID, the present invention enables the web designer to use the 
10 default prefix 80 with fields which are inserted directly inside existing HTML tags 
91 or attributes 92L This Ls exposed syntax. That is, the field names 82 will show up 
on input page 15 dming design time. This kind of syntax makes it easier for ftie 
designer to tell where the dynamic content is located, but makes it harder to get a 
sense of what the actual run-time page will look like. In addition, in exposed 
15 syntax, any dynamic links, images, or other page properties may appear broken 
to flie designer until the actual run-time page is served. Generic tag content 90 
illustrates the use of an exposed, specially prefixed fieldname 82 inserted between 
two tagnames 91. Generic tag attribute 92 shows use of a specially prefixed 
fieldname 82 as an attribute 92. 

20 Figure IE shows the use of hidden syntax. In this syntax, field names 82 are 

hidden as either generic tag content 100 or generic tag attributes 102. With hidden 
syntax, the designer is free to use "dummy" data throughout input page 15 for a 
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better sense of how the rimtime document will look. At run-time/ the actual 
values of ti\e field names 82 will be supplied. 

In most preseit browsers designed for the Worldwide Web, a browser does not 
send the web server the same infommtion that it receives from a web server. 
5 Whai sending information, the browser sends only the information in a URL 
(Uniform Resource Locator) and a simple list of HTML parameters and their 
values. These are either attached to the URL or are sent separately along with the 
URL when submitted from a Form using the "POST" method. See Figure 4A(Prior 
Art).Thus, if a page has both queries and updates, tiie specially prefixed fields will 

10 be used by the present invention to populate data into web pages that are sen.'^ed. 
However, die browser at the user's location doesn't send bads those same fields 
- to the web server when it submits the form, because HTTP does not permit th«n. 
Instrad, the browser only sends back the HTML parameter list based on the 
names defined in the HTML FORM. These parameter names are standard HTML 

15 and do not use or need dae special prefix syntax of the present invention. 

The present invention supports Ais situation by allowing one set of mappings to 
be active when the web page is served from a query, and a different set of 
mappings to be active when a form is used to update. On the query, the 
invention maps the spedaily prefixed fields. On a form update, the invention 
20 maps the HTML parameters defined by the form. The present invention also 

allows a query definition to set default values, attributes, and selection lists for all 
the form's fields, as well as the form's action attribute and other page properties. 
Other client programs, sudi as ^edal Java application programs can send back 
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data in any fonnat, including files, which can also be handled by liie present 
invention. Usually, such special programs will use the same sets of fields as the 
ir\putpage. 

Turning now to Figures IF-IJ, the syntax and context analysis iised by the present 
5 invention to foitnat repeating fields is illustrated. When a user is accessing 

dynairuc data from a daiabase, the same field in a document may be repeated in 
the display document multiple times, each time having a different value. 

When the virtual server of the present invention (discussed in more detail below) 
creates an XML document from back-end data, (database 00) at run-time, it may 
10 repeat ttie same field in that document multiple times, each time with a different 
value- To format these repeated fields, the DCI 18 of the present invention 
generates, at design time, style sheets 25 capable of repeating both the fields and 
tf\e surrounding HTML formatting tags. 

Da 18 also allows nesting of repeated fields and formatting widiin other 
15 repeating fields and formatting. A designer controls repeating formatting for 
fields based on placement of the fields in an HTML page and on the structure of 
the hierarchical node names shared by the repeated fields. DCI 18 and virtual 
server 54 of present invention arudyze the prefixes and flie context of these 
formats to determine the repeat patterns. 

20 In Figure IF, the method for repeating table rows is shown. In the embodiment 
shown, all fields share a common root node which associates all fields with their 
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parent document. Since this node is automatically part of all field names and 
designers do not visually enter it, it is not considered or shown in the examples 
below. In Figure IF^ a table row is repeated once for each time the first riode 
(reading the field left to right) is shared by all repeating fields in the row. Any 
5 static text in the row repeats when the row repeats. All row and cell attributes 
(such as border and background color) also repeat 

In Figure IF, table 114, only die second row 112 has a specially prefixed fieldname 
8Z The fieldname 82 has a single node Nl called here "itemfeature*\ The second 
row will therefore be repeated once for each occurrence of "itanfeature" in the 
10 run-time XML document. 

Thus, as shown by table 116 of Figure If, if there is only one actual occurrence of 
an "itemfeature" (here the actual itcmfeature is "It's cheap!) when the backend 
data from the database is served by server 54 in an XML format, then the example 
of row 120 will be displayed when the page is served. However, if the field has 
15 several entries in the database, the present invention allows the field formatting to 
be repeatedly applied to them, as seen in Table 118 , rows 122-126 of Figure IF. 

With reference now to Figure IG, the present invention allows a web page 
designer to repeat the formatting for multiple fields sharing the same node. In 
table 130, as it appears at design time, row 132 has two static fields (Product Name 
20 and Product Features) and row 134 has two dynamic fields, as indicated by the 
special prefix 82, psx in this exairyle. The fornuitting specified by the designer for 
these fields will be as seen at nmtime in Table 140, when Ihe dynamic data for 
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them has been retrieved and served. Here, the static row 142 is not repeated, but 
for each dynamic occurrence of a product name, one or more product features 146 
are shown and formatted as originally specified by the web page designer. Each 
product appears on a new row and witiKin that row the features are listed^ It 
5 should be noted in these examples, that the formatting shown here which indudes 
the prefix and node names is frue formatting defined by the desigr\er at design 
time - -in Figure IG, that is table 130. The results - -here table 140 of Figure IG- - 
are provided by virtual server 54 of the present invention in a display document 
in response to that formatting and to the actual results from database 00. 

10 Turning now to Figure IH, it can be seen that the embodiment shown also allows 
repeating of rows within rows. In Figure IH , table 150 is defined at design time. 
In table 150, the outamost table row 152, repeats for the first ^ared node Nl 
(from left to right), the second table row 154 inward repeats for the second shared 
node N2 (continuing to right) and so on continuing inward until either all nested 

15 tables or shared nodes are exhausted. This formatting is described by DCl in an 
XSL style sheet and the dynamic data is id^atified by DCl 18 in a DTD format 
dynamic content definition 28. When dynamic data is retrieved at runtime about 3 
different productsl58,162,164, each having one or more featuresl70472,174,176, 
the XSL style sheet 25 and the dynamic content definition 28 created at design 

20 time are applied by the invention's virtual server so that the information is 
displayed as shown in table 156 of Rgure IH . In Figure IH note that the static 
content 160 "Take a look at these features!" is repeated with each occurrence of 
the product/name/ while the changeable, dynamic content about products and 
features has been arranged as shown in Table 156. 
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All Other repeatable formats nested wittun a table, such as tire bulleted list shown 
in Figure II, / exhaust the shared nodes <from left to right) in the order of 
outermost to innermost repeatable formatting. Those skilled in the art will 
appreciate that otiier methods for analyzing the context and sjmtax could be used 
5 without deviating from the present invention. Special characters or indicators 
could be used, for example, or context might be analyzed differently. 

Figure IJ illustrates how time DCI 18 of the present invention can be used to format 
forms from a browser, applying the same analysis. 

Now turning to Figure IB, virtual server 54 of the present invention is shown. In 
10 the embodiment shown, a standard web server 52, such as Microsoft 
Corporation's Internet Information Server (IIS) web server is used, and 
Microsoft's standard Windows ISTF^ operating system 50 is used as well As will 
be apparent to those skilled in the art, ottier web senders, operating systems, and 
network protocols could be used without deviating from the spirit of the present 
15 invention. Figure IB illustrates the relationship of the invention's design time tools 
- -data access page request definition generator 19 and web page designer's DCI 
18* ' with actual nmtime programs, such as the present invention's virtual server 
54, and other wdb applications 60, web browser 70, and database 00. 

Turning briefly to Figure 4B, an overview of the operation of virtual server 54 of 
20 the present invention is shown. When a query request is made from a user at UU, 
it is translated by the web browser into standard http protocol requests S5, such as 
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GET URL. POST Body, and forwarded to the webserver machine S15. There the 
webserver 52 maps the URL to find the predefined request object handler 32 of 
the present invention's virtual server 54. Predefined request object handler 32 
uses the dynamic content definition 28 created at web page design time in DTD 
5 format, and data access definitions 32b created at data access design time to find a 
database 00, to get the data at block 25, and ftien to generate tiie reply in XML 
f onnat that will be combined by virtual server 54 with the previously defined XSL 
style sheet to create a web page display document DD that has all the dynamic 
fields requested and formatted as the web page designer intended. 

10 In the embodiment shown, virtual server 54 automatically generates and serves 
viriiial, hierarchically structured documents from structured data stored in a 
variety of data schemas (relational, tabular, indexed, hierarchical) in a database 00, 
In addition, all data transformations necessary to map from the storage schema 
of database 00 into the front-end display document DD hierarchy schema may be 

-15 defined visually without the need for any code, (as described below) thus 

simphfying the data access logic as well. The data retrieval and data processing 
logic are pre-compiled and optimized when the virtual server 54 process is started. 
No run-time code is gmerated nor is any code interpreted while processing run- 
time requests. The transformation mappings done by virtual server 54 allow 

20 structured data organized in rows and columns to be automatically repeated or 
collapsed as necessary to fit a hierarchical document's content structure. 

In the embodiment shown, no physical input page 15 was actually stored on disk 
at design time by DCI 18. Instead, an input web page 15 in the present invention 
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is a virtual document described by XSL style sheet 25 and dynamic content 
defini don 28. Consequently, in the present invention, a request for such a 
virtual document appears the same (uses the same request syntax) as a request for 
an actual physical document being served from disk, although the document in 
5 the case of the present invention is entirely virtual. Because titie document is 
virtual, no physical web page document need be stored on, or requested from 
disk in order for the final display document DD to be served. 

In other words, while prior art approaches usually store a physical document - - 
such as input page 15- - containing HTML formatting and embedded code , the 
10 present invention's virtual server 54 generates a virtual document at runtime, 
based on the parameters stored in the predefined request definition object data 
access definitions 32b and XSL style sheet 25. 



Virtual server 54 of the present invention botii generates and serves XML and 
HTML documents via the HTTP protocol from various back end data sources- - 

15 database 00 - -including relational SQL (Standard Query Language) databases, 
odier XML or HTML files, hierarchical databases (AS/40D), and file systems, 
among ottiers. This allows die data access logic and design to be completely 
separated from the "look and feel" of the web page design. Returning to Figure 
1 A for a moment, page request definition generator 19 is used by the data access 

20 designer to create the data access definitions 32b that are stored in page request 
object data access definitions 32b. 



Now referring to Figure 4C, when a request R is made by a user UU, it travels 
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using standard HTTP protocol over the Intemet II to computer S15/ which is 
running an operating system SO, a webserver 52 and the present invention's 
virtual server 54. Virtual server 54 executes the page request object handler 32 
which is associated with the fields in the request and uses the data access 
5 definitions 32b, which were created by the page request definition generator 19, to 
access database 00 and find data 01 which meets the request R. The data access 
definitions 32b can be defined to work with data 01 in a number of common 
formats, or schemas, such as relational databases, flat fields databases and so on. 
The data access definitions 32b are used to find the database 00 and make the 
10 appropriate read or write requests against it 

In the embodiment shown in Figure 4C virtual server 54 maps the data 01 found 
into XML format using the dynamic content definition 28 created by DQ 18 at 
web page design time. As part of this processing, the formatting defined in style 
sheet 25 is applied to both the dynamic and the static content of the data found 

15 and ftte virtual display document DD being created. When formatting is 

completed^ virtual web page display document DD is sent back to the user UU 
over the Internet 11, using the standard webserver software 52. As seen in this 
example, display document DD is not stored at the webserver site or in the 
database OO but is created dynamically in accordance with the parameters that are 

20 stoied in page request object XML mappings 32a and data access definitions 32b, 
XSL style sheet 25 and dynamic content definition 28. In the embodiment shown, 
page request object handler 32 includes handler code which accepts the 
information in the data access definitions 32b, dynamic content definition 28 and 
XSL style sheet 25 as parameters to be used in satisfying the request R. Thus, no 



wo 01/18656 PCT/USO0/24695 

-22- 

code is embedded in display document DD. This makes it easy for the data access 
logic to be changed without affecting the web page formatting and vice versa. 

In addition, Ihe mapping to XML format performed by the invention 's virtual 
server 54 is also simplified by use of the current invention's visual mapper 33, 
5 shown in Figure 4D. As seen there, the data access designer can use visual mapper 
33 to specify how data 01 found in database .00 should be mapped into XML fields 
and formats stored in XML mappmg 32a. Since this mapping is done at data access 
design time, it turns ttie actual mapping at runtime into the application of 
predefined parameters. 

10 Turning back briefly to Figure IG, an example of XML 141 generated by page 
request object handler 32 in virtual server 54 of the present invention is shown. 
When page request object handler 32 applies the XSL style sheet 25 formatting, 
and the dynamic content definition 28 at runtime, the restdts will appear as table 
140 when that particular request is handled. 

15 With reference now to Figure 1 A again, page request definition generator 19 of 
ttie present invention is used by the data access designer, at design time to create 
data access definitions 32b of the page request object handler 32. Thus, at run 
time, page request object handler 32 will have as input parameters the XML 
mapping resulting from dynamic content definition 28 and the data access 

20 definitions 32b, as well as XSL style sheet 25. 



This enables virtual server 54 of the present invention to take advantage of the 
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dynamic content definition 28 to determine what the output format should be. 
Dynamic content definitions 28 can also contain information regarding the 
lepetitiveness of the data elements. For instance, if there is a table in database 00 
called orders with the following structure: 

5 orderjd Item 

123 1 

123 2 

123 3 

456 1 

10 456 2 

there are many ways to create an XML docuinent from this data. One way to 

force the structure is to build the dynamic content definition 28 in the appropriate 
manner. For example: 

<!ELEMENTOrdCTS (Order*)> 
15 <!ELEMENT Order 0^temList)> 
<!AmiST Order 

id ID #REQUIRED> 
<!ELEMENT ItemList (item*> 
<!ELEMENTLtem (#PCDATA)> 

20 This has Orders as a root node which contains Order elements. Looking at the 
above dynamic content definition 28, there is an asterisk next to Order in the 
Orders element dedaralion. This indicates that Order is a repeating entry. Order 
contains a single attribute, the order id. That maps to an orderjd coltmnn. There is 
also an ItemList element which contains item elements. The item elements map to 
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the item coluinn. Once agaiiv from the dynamic content definition 28 it is seen that 
item is a repeating entry. The id attribute, on the other hand, cannot repeat, 
because attributes cannot repeat in XML. Based upon these relationships, the 
present invention makes a few determinations: 

5 - -the id attribute of the Order element must be the identifier for item entries. This 
means that for each matching id (orderjd in the back-end) the invention creates 
one ItemList entry. It dten collapses multiple item entries into Iheir matchmg 
ItemList entry. 

Since the id attribute (orderjd column) is the key, the back-end query must be 
10 sorted on orderjd. If "Use WHERE table'* is specified in die data selector on the 
query pipe and no sorted columns have been specified, the present invention will 
define orderings (ORDER BY) in li\e SQL statement issued to the back-end 
database 00. If sorted columns have been specified, or "Manually enter SQL" has 
been chosen, the user must be sure to properly sort the data. In the above 
1 5 example, the user wants to collapse items based upon their order id. 
Consequently, the invoition will sort on the orderjd column. 

This would cause the following XML to be generated: 

<Qrders> 

<Orderid=123"> 
20 <ItemList> 

<item>l</item> 
<Ltem>2</item> 



wo 01/1«656 PCT/USOO/24695 

-25- 

<item>3</itein> 
</ItemList> 
</Order> 
<Orderid="456"> 
5 <ItemList> 

<item>l</item> 
<item>2</item> 
</ItemList> 
</Ofder> 
10 </Orders> 

If a slight change is made as follows, to the dynamic content defiiution 28 : 

<!ELEMENT Orders (Order*)> 
<!ELEMENT Order {item)> 
<!ATnJST Order 
15 id ID #REQUIRED> 

<!ELEMENT item (#PCDATA)> 

onoe again Orders is a root node which contains Order elements. Order contains 
the order id, but now it contains the item element directly. This structure indicates 
there are repeating Order elements, but id and item are now a one to one match. 
20 For this model, the invention makes no assumptions about sorting requirements. 
It would now generate the following XML; 
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<Orders> 

<Or<ierid="m"> 

<item>l</it€m> 
</Order> 
<Orderid=n23'^> 

<item>2</item> 
</Order> 
<Orderid="123"> 

<item>3</item> 
</Oi:der> 
<Orderid=="456"> 

<item>l</item> 
</Order> 
<Qrderid="456"> 

<item>2</item> 
</Order> 
</Orders> 

Further complicating query mappings, ftie data may contain conditionals which 
can change the way data is mapped For example, asstime the data contains a 
phones table as follows: 



phonejd contjd phone^type phone^no 
1 1 H 111-1111 
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2 1 B 222-2222 

3 1 F 333-3333 

4 2 B 444-4444 

5 2 F 555-5555 

5 and the followmg dynainic content definition 28 is generated: 

<!ELEMENT Coatacts (Contact*)> 
<!ELEMENT Contact (Phones)> 
<!ATTLIST Contact 

id ID #REQUIRED> 
10 <!ELEMENT Phones ((home | business | fax)*)> 
<!ELEMENThome (#PCDATA)> 
<!ATTLISThome 

id ID #REQU1EED> 
<!ELEMENT businfiss (#PCDATA)> 
IS <!ATILIST business 

id ID #RBQt3IEED> 
<!ELEMENTfax (iH'CDATA)> 
<!ATrLISTfex 

id ID #REQUIRED> 

20 In diiis example, first note that the Contacts/Contact dement is repeating. It's id 
attribute maps to the contjd colvonn. This tells the presait invention it will be 
sorting on contjd and oallapsing phone rea>rds into the Phones dement The 
pipe character in the Phones element declaration signifi^ that the Phones element 
contains home, business or fax elements. Furtt\ermore, the asteri^ signifies that 

25 there may be many of these. To get the phone numbers into the appropriate 
places, the data access designer builds a mapping such as the following: 



XML Field 

Contacts/Conlact/@id 



Back-End Column Conditionals 
contjd 
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Contad:5/Contact/Phon^/home/@id 
H 

Contacts /Contact/Phones/home 
H 

5 Contacts /Contact/Phoi^s/business/® 
B 

Qjntacts/Contact/Phones/bvisiness 
B 

Contacts/Contact /Phones /fax/ @id 
10 F 

Contacts/Contact/Phones/fax 
F 



phone_id 


phone Jype = 


phone^no 


. phane_type = 


phone Jd 


phone^type = 


phone_no 


phone_type = 


phonejd 


phane_type = 


phone_no 


phone_type = 



As the mvention processes the data, in the embodiment shown, it will first create 
the Contacts/Contact element and set the id to the contjd column value. For each 

15 matching cont^id value, it will then look at the conditionals phone^type column 
value to determine what to do. If the column contains 'H' as iVs value, it will create 
a Contacts /Contact/ Phones/home element containing the phone^no column's 
value and set the id attribute to the phone^id column's value. If the phone_type 
column contains 'B' or T' it will create the business or fax element in the same 

20 fashion. Based upon the data specified above, tihe following XML document is 
generated: 



<Contacts> 

<Contact id="l"> 
<Phones> 



25 



<home id="l''>lll-llll</home> 
<biasiness id="2">222-2222</business> 
<fax id=3">333-3333</fax> 
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</Phones> 
<Contact> 
<Contact id="2'^> 

<Phones> 

5 <business id=M">444-4444</busmess> 

<fax id="5">555-5555</fax> 
</Phones> 
<Contact> 
<Contact5> 



10 When performing updates, inserts or deletes, the embodiment of the invention 
shown here needs an attribute or element to be defined which tells it which of 
ttiese tturee actions it shoidd take. 



Unlike query mappings which take advantage of the dynamic content definition 
28, update mappings rely heavily upon the XML mapping definitions 32a and the 
15 input data structure- For example with the following XML document: 



<Contacts> 

<Contactid="l"> 

<Phones DBActionType="UPDATE'^ 

<home id="l">llMlll</home> 
20 <businessid="2">800-222-2222</lnisiness> 

<fax id=:"3'*>333-3333</fax> 
</Phones> 
<Contact> 
<Contactid="2"> 
25 <Phones> 

<busii\ess id="4">444-4444</business> 
<fax id="5">555-5555</fax> 
</Phones> 
<Coiitacl> 
30 <Contacts> 
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there is an added attribute, DBActionType^ to the Phones element. When 
performing updates^ inserts or deletes, the page request object handler 32 of the 
present invention needs an attribute or element to be defined which tells it which 
of these three actions it should take. The system would then see a need to 
5 update the phone numbers for tfie first contact, but skip the second contact. 

This entails applying data from multiple XML fields into the same back-end table. 
To do this, the data access designer has created a set of mappings for each XML 
group to its corresponding back-end group. By repeating the back-end column 
entries, the present invention will process each group of entries as a separate 
10 update to the back-end database 00. 

Enabling users to navigate, link, or "drill down" from one page to the next is also 
provided for by the present invention. In its simplest form, the data access 
designer can simply use a request URL on the "source" (current) page to point to 
the next successive *'target" page. However, in a dynamic environment things 
15 quickly get more complicated. The request URL to the"targ€t*' page needs to 
supply more information in order to get the right type of dynamic content 

For example, in a static environment with only one person^ the request URL needs 
to only specify '*person.htm" but in a dynamic content environment with many 
people, tiie URL would need to specify 
20 ''person,htm?firstname=Joe&lastname=Smith" in order to get the exact person 
page for "Joe Smith"- 
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Complicating issues further, the source page may itself have been created 
dynamically based on some other request. Suppose for example^ the source page 
contained a list of people to choose from by name^but now the target page 
required an employee ID number to locate any specific person such as, 
5 "pei5onJhtnx?empIoyeeid=123'\ Here, though the source page is designed to 
show 

people by name, it would have to "know ahead of time" that it is linked to a 
target page which requires the employee ID number and not the person's name. 
Otherwise, the source page would be delivered without the employeelD and it 
10 would not be possible to link it to the target page. Furthermore, if the target 
page is changed to use something other than employee ID, then the source page 
would have to be kept in syncii or the links could be broken. 

The present invention solves these problems through the use of navigation links. 
As seen in Figure 14, the data access designer visually links the "soiurce" data 

15 request 1400 to all the other possible "target" data requests, 1402,1404,1406 etc., 
that could be Imked to from that source. When this is done, the "source" request 
handler auto-generates all the possible URLs required to link from the source web 
page to the target pages. Each of these URLs are placed in the "source", in addition 
to the other data defined by that source request If a linked target resource 

20 definition is altered to reqxure a new type of request URL, the source request 
handler is also altered so as to generate the new URL to the target resoiuxe. 



These autogenerated URLs may be used however the designer wishes in the 
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actual 

pages returned.. Most often, ttie URL is placed as the contents of the HREF 
attribute on the A (anchor) tag to allow for hypertext linking between 
documents. However, it is also commonly used in the SRC attribute of the IMG 
5 tag (for navigation links attached to non-text resources), or the ACTION 
attribute of tfie FORM tag (for navigation links attached to update resources), 
or anywhere else a standard URL is used in an HTML page or other client 
application. 

When a "source" request is linked to a "target" request at design time, the 
10 subsequent request handler for the "source" is created with additional properties 
as follows for each linked target. In the embodiment shown, the "source" request 
must always be a query, 

1. The target request definition is examined to determine any required request 
parameters. 
15 2. If the target is a query: 

a. The data selection properties for the target are determined. 

b. Required data for selection is mapped to request parameters for the URL 

c. The source request handler is updated to include processing of the 
additional parameters into valid URL syntax. 

20 3. If the target is an update the links may be defined to allow updates, 
inserts, or deletes. There are two cases to be considered: 
a. URLs for inserts 

L Only the request properties for tt\e target are mapped to request 
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parameters for the URL. 

ii. The source request handler is updated to include processing of the 
additional parameters into valid URL syntax, 
b. URLs for updates or deletes 
5 i. The data update properties for the target are determined- 

ii. Required key data for the update is mapped to request parameters 
for the URL 

iii. The source request handler is updated to include processing of 
die additional parameters into valid URL syntax. 

10 At run hme, the request handler for the "source" page now includes the 

necessary mechanisms to generate all the URLs to each linked target. When the 
source page is processed, the additiortal URL generation takes place^ and the 
URLs are included with the source document when it is served. 

Detailed flow diagrams illustrate the logic of the embodiment shown. Beginning 
15 with Figure 15, DCI 1 8's processing of ttie HTML nodes is shown* An input page 
15, here shown as HTML 1500 is analyzed HTML node by HTML node, as 
illustrated at step 1502. Once an HTML node is selected, Dd 18 checks to see if it 
has child nodes at decision block 1504. If it does, DCI 18 loops through each HTML 
childnode imtil the last or innermost is foiuid' When that is found, processing 
20 proceeds at step 1510, to process all the HTML node inforiruition from static text at 
1512^ to other attributes at 1538» The prefix and context analysis described above 
is applied to each, as appropriate. Then DCI 18 corrects the node context at step 
1540, transforms the HTML node to an XSL node at 1510, and replaces the older 
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one, if any. Processing continues in this manner at 1506 for each HTML node in 
the child node list. When processing is completed, an XSL style sheet 25 and a 
dynamic content definition 28 have been created. 

Turning now to Figure 5, initiation of the invention's virtual server 54, hare 
5 referred to as E2 is shown. At step 500 the webserver hook of virtual server 54 
receives a request. At decision block 502 it checks to see if the URL specified in the 
request is in this server's root. If it is not, the event is released imtouched at step 
504, If the request does have a URL contained in virtual server 54's root, the 
invention checks to seek if there is at least on application also in the root, and if the 

10 rest of virtual server 54 is up and ruiming. If not, the event is either released at 
step 508, or the checks for maintenance processing at step 512 through 522 are 
executed. If virtual server 54 is up, the request is handed to its dispatcher at step 
520. At step 524 the input parameters of the request are parsed and then run 
through virtual server' 4's requ^t filters, shown below. Checks are made to see if 

15 the request is tied to an application, or if SSL (Secure Socket Layer or other 

encryption technology is required) and appropriate reports are generated- At step 
542, the invention can check use statistics to select the most available server for 
handling the present request and forward the request to that server. 

Figure 6 is a flow diagram which illustrates some of the pre-processing of the 
20 request done by the present invention. At decision block 602, the system checks 
to see if raw input data exits have been defined by the user, and if they have, an 
exit handler is executed for each one specified at step 610. Exits, as they are defined 
in the embodiment shown, are custom code a data access designer may have 
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written. While it is a goal of the present invention to minimize ttie need for any 
cuslom code, it also permits such code to be included by a data access designer, if 
desired. If no special exits are need, the invention proceeds to step 604 to map the 
input data in the request to the bad:*end data in database 00, by mapping names, 
5 and converting data tj^es as necessary. If this succeeds, processing flows to the 
statement builder at step 618* 

The statement builder of the present invention is shown in Figioe 7. Essentially, 
the statement builder determines what kind of data access is required. As seen at 
block 710, if a simple query is required, processing proceeds to execute the query 
at step 718, If an insert is requested, that processing is selected, and so on. Figure 
8 illustrates the processing to execute a query, Figure 10 illustrates the logic for 
inserting data. Figure 12 illustrates update processing, and Figure 13, delete 
processing. Figure 11 shows the processing of an actual transaction against 
database 00^ and Figure 9 illustrates the generation of the results. As seen at step 
926 in figure 9, the results are the generated HTML display document DD. 



10 



15 



In the embodim«its shown, Windows NT- compatible personal computers and 
workstations are used to implement the present invention. However, those skilled 
in the art appreciate that o(her computer platforms such as SUN Microsystems 
workstations, or IBM Mainframes could be used as well, either in client server or 
20 centralized or distributed network configurations. While the embodiments shown 
are programmed using C++, other programming languages can be used as welL 
Similarly, while software has been used along with the above computer systems 
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to implement the invention, part or all of the invention could be included in 
firmware or hardware circuitry without deviating from the spirit of the presait 
Invention, 
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Claims 

What is claimed is: 

1. A method for generating a virtual display document containing dynamic 
content over a network in response to a request, comprising the steps of: 

5 accessing dynamic data in a database using a previously generated dynamic data 
access definition; 

applying a previously generated style sheet to format the static fields of the virtual 
display document; 

appljring a previously defined dynamic content definition for the virtual display 
10 document which describes how dynamic fields are to be formatted; and 

dynamically serving a virtual display document formatted accordingly in response 
to the request. 

2. The method of Claim 1, wherein the step of accessing dynamic data in a 
database using a previously generated dynanuc data access defirution further 

15 comprise d\e step of using the data access definition to find the database and 
make the appropriate input and ou^ut requests to the database. 

3. The method of Claim 1 wherein the step of accessing dynamic data in a 
database using a previously generated dynamic data access definition ftirther 
comprises the step of using the previously generated dynamic data access 

20 definition to work with data in any of a plurality of common formats. 

4. The method of Qaim 1, wherein the step of dynamically serving a virtual ' 
display dociunent further comprises the step of mapping data access definitions. 
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style sheets and dynamic content definitions to generate the virtual display 
document. 

5, The method of Claim 4, wherein the step of mapping data access definitions, 
style sheets and dynamic content definitions further comprises the step of 

5 mapping data access definitions/ style sheets and dynamic content definitions into 
XML format. 

6. The mettiod of Claim 4, vsrherein ttie step of mapping data access definitions, 
style sheets and d>'namic content definitions is performed dynamically by a page 
requ^t object handler* 

10 7. The method of Qaim 6, wherein tfie step of mapping data access definitions, 
style sheets and d5mamic content definitions further comprises the steps of: 
- - mapping the correspondences between data access definitions, style sheets and 
dynamic content definitions and XML fields and formats at design time and 
storing the mapping results in the database; and 

15 - -using the page request object handler to apply the mapping results when the 
virtual display document is served. 

8. The method of Claim 7 wherein the stqp of mapping the correspondences is 
done by a visual mapper. 

9. An apparatus for generating a virtual display document containing dynamic 
20 content over a network in response to a request, comprising: 

means for accessing dynamic data in a database using a previously generated 
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d)maimc data aocess definition; 

means for applying a previously generated style sheet to format the static fields of 
the virtual display document; 

means for applying a previously defined dynamic content definition for ttie 
5 virtual display document which describes how dynamic fields are to be formatted; 
and 

means for dynamically serving a virtual display document formatted accordingly 
in response to the request 

10. The apparatus of Claim 9, wherein the means for accessing dynamic data in a 
10 database using a previously generated dynamic data access definition further 

comprises means for using the data access definition to find the database and 
make the appropriate input and output requests to the database. 

11. The apparatus of Claim 9 wherein the means for accessing dynamic date in a 
database using a previously generated dynamic data access definition further 

15 comprises means for using the previously generated dynamic data access 
definition to work with data in any of a plurality of common formats* 

12. The apparatus of Claim 9, wherein the means for dynamically serving a virtual 
display document further comprises means for mapping data access definitions^ 
style sheets and dynamic content definitions to generate the virtual display 

20 document. 



13. The apparatus of Qaim 12, wherein the means for mapping data access 
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definitioiis, style sheets and dynamic content definitions furttier comprises means 
for mapping data access definitions, style sheets and dynamic content definitions 
into XML format, 

14. The apparatus of Qaim 12, ivherein the means for mapping data access 

5 definitions, style sheets and dynamic content definitions is performed dynamically 
by a page request object handler, 

15. The apparatus of Claim 14, wherein the means for mapping data access 
definitions, style sheets and dynamic content definitions further comprises: 
means for mapping the correspondences between data access definitions, style 

10 sheets and dynamic content definitions and XML fields and formats at design time 
and storing the mapping results in die database; and 

means for using the page request object handler to apply the mapping results 
when the virtual display document is served. 



15 



16. The apparatus of Claim 15 wherein the means for mappii^ the 
correspondences is a visual mapper. 
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